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Real Party in Interest 

The real party in interest is Siemens Enterprise Communications GmbH and its related 
United States company Siemens Enterprise Communications Inc. 

Related Appeals and Interferences 
There are no related appeals or interferences. 

Status of Claims 

Claims 24-29, 3 1-34, 44-52 and 54 have been and are currently pending in the 
application. The status of the claims is that claims 24-29, 3 1-34, 44-52 and 54 have been 
rejected. Claims 1-23, 30, 35-43, and 53 have been canceled. Applicants are appealing the 
rejection of claims 24-29, 31-34, 44-52 and 54. 

Status of Amendments 

A request for reconsideration was filed on June 17, 2010 in response to the Final Office 
Action of April 20, 2010 (hereafter "the Office Action"), from which this appeal is taken. This 
request for reconsideration was entered by the Examiner. 

Summary of Claimed Subject Matter 

The pending claims are directed to a method for the transmission of software and/or data 
on demand from a server to a terminal in a packet network and a computer device configured to 
utilize such a method. (Specification, at page 1, lines 8-9 fl[ 2)). 1 There are no means plus 
function limitations in the pending claims. Figures 1 and 3 illustrate embodiments of a 
computer, such as a server, that has various functional units of the claimed invention. Figures 1 



1 Citations to the specification by paragraph numbers identity paragraphs in the Substitute Specification submitted 
on March 29, 2006. The paragraph numbers are also provided herewith along with specific citations to page and 
line numbers of the Specification to help make the cited portions of the Specification easier to find. It should be 
appreciated that citations to a particular portion of the Specification indicate that there is at least support for those 
limitations at the cited portion(s) of the Specification. 
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and 4 illustrate block diagrams of network arrangements that may utilize embodiments of the 
claimed invention. 

Claim 24 is directed to a method for substantially real time transmission of a software 
component after receiving a demand for the software component from a requesting terminal of a 
network comprised of a server and a plurality of terminals. (Specification, at page 1 , lines 8-9 (f 
2; Figures 1-4)). The requesting terminal is one of the plurality of terminals. (Specification, at 
page 3, lines 21-23 fl[ 15); page 8, lines 15-17 flf 36)). The method includes the step of 
triggering a bandwidth test. (Specification, at page 3, lines 7-9 fl[ 12); page 10, lines 3-4 flf 42)). 
The bandwidth test includes sending a bandwidth request to each terminal (Specification, at page 
16, lines 1-4 (% 66)), registering a bandwidth of an associated part connection after each hop 
(Specification, at page 16, lines 1-12 (ff 66-67)), and receiving assembled data relating to 
bandwidth available for each terminal (Specification, at page 16, lines 1-12 flffl 66-67); Table 2). 
Prior to initiating transmission of the software component, it is determined via the bandwidth test 
if a present bandwidth is sufficient for transmission of the demanded software component to the 
requesting terminal by identifying at least one lower priority process currently using bandwidth 
of the existing network that each has a lower priority than the demand and computing an amount 
of available bandwidth resources that is obtainable from reducing bandwidth resources assigned 
to the at least one lower priority process. (Specification, at page 4, lines 1 8-27 flf 19)). If the 
computed amount of available bandwidth resources is equal to or greater than an amount of 
bandwidth necessary to transmit the software component to the requesting terminal, the one or 
more lower priority processes are reduced or frozen and the software component is transmitted to 
the requesting terminal (Specification, at page 4, lines 18-27 (f 19); page 15, lines 6-24 (Iff 63- 
64)). If the computed amount of available bandwidth resources is less than the amount of 
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bandwidth necessary to transmit the software component to the requesting terminal, the 
transmission of the software component is inhibited or rejected. (Specification, at page 5, lines 
5-12 (f 21); page 10, lines 15-28 (f 43)). 

Claim 25 depends from claim 24 and requires that the amount of available bandwidth 
resources also be calculated according to a specified upper limit of a transmission time for 
transmitting the software component to the requesting terminal Support for the limitations of 
claim 25 may be found at least at page 4, lines 1-4 (| 16) of the Specification. 

Claim 26 depends from claim 25 and requires that the amount of available bandwidth 
resources is available to the requesting terminal and is included in the demand. Support for the 
limitations of claim 26 may be appreciated at least from page 4, lines 5-7 fl[ 17) of the 
Specification. 

Claim 27 depends from claim 26 and requires the server to have access to the software 
component and the amount of available bandwidth resources. Support for the limitations of 
claim 27 may be found at least at page 3, lines 7-12 flf 12), page 8, lines 1 5-17 flf 36) and page 9, 
lines 9-15 39) of the Specification. 

Claim 28 depends from claim 27 and requires the bandwidth test to provide a positive test 
result if the amount of available bandwidth resources is suitable for a real time application or if 
the amount of available bandwidth resources is suitable for a substantially real time application. 
Support for the limitations of claim 28 may be understood from at least page 9, lines 1-8 fl| 38) 
of the Specification. 

Claim 29 depends from claim 27 and requires the information regarding the present 
bandwidth be made available by a network resource manager and be updated on request by the 
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server or after a period of time. Support for the limitations of claim 29 may be found at least at 
page 12, lines 8-12 (f 48) of the Specification. 

Claim 31 depends from claim 29 and requires a message to be sent to the requesting 
terminal that includes a temporary or permanent rejection of the load request if the amount of 
available bandwidth resources is less than the amount of bandwidth necessary to transmit the 
software component. Support for the limitations of claim 3 1 may be understood from at least 
page 10, line 22 through page 11, line 5 fl[ 43) of the Specification. 

Claim 32 depends from claim 31 and also includes the step of displaying the message to a 
user of the requesting terminal. Support for the limitations of claim 32 may be found at least at 
page 6, lines 1-3 fl[ 25) of the Specification. 

Claim 33 depends from claim 31 and also includes the step of generating a load request in 
response to the temporary rejection of the load request. Support for the limitations of claim 33 
may be appreciated from at least page 5, lines 5-18 flflf 21-22) of the Specification. 

Claim 34 depends from claim 31 and also required that a permanent rejection be 
generated after a plurality of temporary rejections have been generated for a load request for the 
software component or after determining that the amount of bandwidth necessary to transmit the 
software component is greater than a maximum available bandwidth. Support for the limitations 
of claim 34 may be understood from at least page 5, lines 8-1 1 and 18-22 (H 21 and 23) of the 
Specification. 

Claim 44 depends from claim 24 and requires the amount of bandwidth necessary to 
transmit the software component be at least partially defined by a transmission rate requirement 
provided in the demand. Support for the limitations of claim 44 may be found at least at page 
11, lines 16-22 (| 45) of the Specification. 
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Claim 45 depends from claim 44 and requires the amount of available bandwidth 
resources to be calculated by a network resource manager that is connected to the server. 
Support for the limitations of claim 45 may be appreciated from at least page 12, liens 8-12 (f 
48) of the Specification. 

Claim 46 depends from claim 45 and requires that the network resource manager be 
connected to an available bandwidth memory that has data on bandwidths assigned to processes 
using network bandwidth resources and priorities for these processes. Support for the limitations 
of claim 46 may be understood from at least page 12, lines 13-17 (f 49) of the Specification. 

Claim 47 depends from claim 46 and requires the network resource manager to also be 
connected to at least one of the terminals and the available bandwidth memory to be periodically 
updated with new data for the bandwidths assigned to processes using network bandwidth 
resources and priorities for these processes. Support for the limitations of claim 47 may be 
found at least at page 12, lines 8-17 flffl 48-49) of the Specification. 

Claim 48 is an independent claim directed to a computer configured for connection to a 
plurality of terminals of a network and configured to transmit a software component to a 
requesting terminal of the plurality of terminals after receiving a demand for the software 
component from the requesting terminal if bandwidth necessary for transmitting the software 
component to the requesting terminal is determined to be available. (Specification, at page 1, 
lines 8-9 flj 2); page 8, lines 15-17 (f 36). The computer includes a network resource allocation 
device that is configured to assign resources of the network to the terminals and reassign 
resources of the network from one terminal to another terminal. (Specification, at page 12, lines 
8-12 fl| 48); page 15, lines 6-14 fl| 63)). That computer also includes a performance 
characteristic providing device that is connected to the network resource allocation device and a 
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network resource distribution memory connected to the network resource allocation device and 
the performance characteristic providing device. (Figure 3; Specification;, at page 12, liens 8-16 
(ft 48-49). The network resource distribution memory has stored data on bandwidths assigned 
to processes using bandwidth resources of the network and priorities for these processes. 
(Specification, at page 7, lines 1-7 (f 30)). The computer also includes a network resource test 
device connected to at least one of the network resource allocation device, the performance 
characteristic providing device, and the network resource distribution memory, (Figure 3; 
Specification, at page 12, lines 22-26 fl[ 50)). The network resource test device is configured to 
oversee a bandwidth test, (Id), The bandwidth test comprises sending a bandwidth request to 
each terminal, registering a bandwidth of an associated part connection after each hop in a 
communication path between each terminal and the computer, and receiving assembled data 
relating to bandwidth available for each terminal via any associated part connections in each 
communication path. (Specification, at page 16, lines 1-4 flf 66). The performance characteristic 
providing device is configured to determine whether an amount of bandwidth exists that is 
sufficient for transmission of the demanded software component by accessing the data stored on 
the network resource distribution memory to identify at least one lower priority process using 
bandwidth of the network that each has a lower priority than the demand in the network and 
calculate an amount of available bandwidth resources that is obtainable from reducing bandwidth 
resources of the network assigned to the at least one lower priority process. (Specification, at 
page 6, lines 4-15(ff 26-27)). The network resource allocation device is configured to reduce or 
freeze the network resources assigned to at least one lower priority process and transmit the 
software component to the requesting terminal if the computed amount of available bandwidth 
resources is equal to or greater than an amount of bandwidth necessary to transmit the software 
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component to the requesting terminal. (Specification, at page 14, lines 20-23 fl[ 60)). The 
network resource allocation device is configured to inhibit or reject transmission of the software 
component if the computed amount of available bandwidth resources is less than the amount of 
bandwidth necessary to transmit the software component to the requesting terminal. 
(Specification, at page 14, line 24 through page 15, line 5 flffi 61-62)). 

Claim 49 depends from claim 48 and requires that the computer be a server or be 
comprised of a server. Support for the limitations of claim 49 may be appreciated from at least 
Figure 3 and page 11, lines 23-27 fl[ 46) of the Specification. 

Claim 50 depends from claim 48 and requires that the bandwidth demand data also be 
stored in the network resource distribution memory. Support for the limitations of claim 50 may 
be understood from at least page 7, lines 1-12 fflf 30-31) of the Specification. 

Claim 51 depends from claim 48 and requires that the performance characteristic 
providing device be a portion of the network resource allocation device. Support for the 
limitations of claim 51 may be appreciated from at least page 11, lines 23-27 fl[ 46) and page 17, 
lines' 1-7 fl[ 72) of the Specification. 

Claim 52 depends from claim 48 and requires that the network resource allocation device 
also be configured to periodically update the data stored in the network resource distribution 
memory. Support for the limitations of claim 52 may found at least at page 15, lines 26-29 flf 
65) of the Specification. 

Claim 54 is an independent claim directed to a method for substantially real time 
transmission of a software component after receiving a demand for the software component from 
a requesting terminal of a network comprised of a server and a plurality of terminals. 
(Specification, at page 1 , lines 8-9 (f 2)). The requesting terminal is a terminal of the plurality of 
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terminals. (Specification, at page3, lines 21-23 flf 15); page 8, lines 15-17 flj 36)). The method 
includes the steps of triggering a bandwidth test (Specification, at page 3, lines 7-9 (f 12); page 
10, lines 3-4 flf 42), and, prior to initiating transmission of the software component, determining 
via the bandwidth test if a present bandwidth is sufficient for transmission of the software 
component to the requesting terminal by identifying at least one lower priority process currently 
using bandwidth of the existing network that each has a lower priority than the demand and 
computing an amount of available bandwidth resources that is obtainable from reducing 
bandwidth resources assigned to the at least one lower priority process, (Specification, at page 4, 
lines 18-27 fl[ 19); page 5, lines 1-4 (f 20)). If the computed amount of available bandwidth 
resources is equal to or greater than an amount of bandwidth necessary to transmit the software 
component to the requesting terminal, the at least one lower priority process is reduced such that 
the at least one lower priority process is still able to utilize some bandwidth, and the software 
component is transmitted to the requesting terminal, (Specification, at page 4, lines 18-27 (f 19); 
page 5, lines 1-4 (f 20); page 14, line 26 through page 15, line 2 (| 61); and page 15, lines 6-14 
14 (| 63)). If the computed amount of available bandwidth resources is less than the amount of 
bandwidth necessary to transmit the software component to the requesting terminal, the 
transmission of the software component is inhibited or rejected. (Specification, at page 15, lines 
3-5 (162)). 

Grounds of Rejection to be Reviewed on Appeal 

1. Rejection of claims 24-29, 31-32, 44-51 and 54 as obvious in view of U.S. Patent 
Application Publication No. 2004/0158644 to Albuquerque et al. (Office Action, at 5). 
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2, Rejection of claims 33-34 as obvious in view of the combination of Albuquerque 
et al. and U.S. Patent Application Publication No. 2003/0097443 to Gillett et al. (Office Action, 
at 19). 

3. Rejection of claim 52 as obvious in view of the combination of Albuquerque et al. 
and U.S. Patent No. 6,222,856 to Krishnan et al. (Office Action, at 21). 

Argument 

I. Rejection of Claims 24-29, 31-32, 44-51 as Obvious in View of U.S. Patent 
Application Publication No. 2004/0158644 to Albuquerque et al. 

A. Examiner's Burden of Proving Obviousness 

"All words in a claim must be considered in judging the patentability of that claim against 
the prior art." (MPEP § 2143.03). "If an independent claim is nonobvious under 35 U.S.C. 103, 
then any claim depending therefrom is nonobvious." (Id.) 

Obviousness prevents the "issuance of a patent when 'the differences between the subject 
matter sought to be patented and the prior art are such that the subject matter as a whole would 
have been obvious at the time the invention was made to a person having ordinary skill in the 
art.'" KSR International Co. v, Teleflex inc., 127 S.Ct. 1727, 1740 (U.S. 2007) (quoting 35 
U.S.C. § 1 03). To show obviousness, an Examiner must show that the improvement is only "the 
predictable use of prior art elements according to their established functions." KSR International 
Co. v. Teleflex inc., 127 S.Ct. 1727, 1740 (U.S. 2007), 

"A statement that modifications of the prior art to meet the claimed invention would have 
been ' well within the ordinary skill of the art at the time the claimed invention was made' because 
the references relied upon teach that all aspects of the claimed invention were individually 
known in the art is not sufficient to establish a prima facie case of obviousness without some 
objective reason to combine the teachings of the references." (MPEP § 2143.01). Rejections on 
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obviousness cannot be sustained by mere conclusory statements; instead, there must be some 
articulated reasoning with some rational underpinning to support the legal conclusion of 
obviousness. KSR, 82 U.S.P.Q.2d at 1396. 

For instance, an invention that permits the omission of necessary features and a retention 
of their function is an indicia of nonobviousness, In re Edge, 359 F.2d 896, 149 U.S.P.Q, 556 
(CCPA 1966). A conclusory statement to the contrary is insufficient to rebut such an indicia of 
nonobviousness. (See MPEP § 2143.01). As another example, n [i]f the proposed modification 
or combination of the prior art would change the principle of operation of the prior art invention 
being modified, then the teachings of the references are not sufficient to render the claims prima 
facie obvious." (MPEP § 2143.01). Further, "the proposed modification cannot render the prior 
art unsatisfactory for its intended purpose." (MPEP § 2143.01). 

The Supreme Court set forth the "framework for applying the statutory language of § 
103" in Graham v. John Deere Co,, 383 U.S. 1, (1966). KSR International Co,, 127 S.Ct. 1727, 
1734, 82 U,S.P.Q.2d 1385 (U.S. 2007). To make an obviousness determination, underlying 
factual determinations must first be made. Graham, 383 U.S. at 17, The scope and content of 
the prior art must be determined, the differences between the prior art and the claims at issue 
must be ascertained, and the level of ordinary skill in the pertinent art must be resolved. Id 
Moreover, obviousness must not be distorted by using hindsight bias or ex post reasoning. KSR 
International Co,, 127 S.Ct. at 1742 (U.S. 2007) (citing Graham, 383 U.S. at 36). 

Secondary considerations may also be provided to show that an asserted combination 
would not render claimed subject matter predictable or obvious. Graham v, John Deere Co., 383 
U.S. 1, 17-18 (1966). These secondary considerations include failure of others, unexpected 
results and the prior art teaching away from the invention. Id, at 17-18; In re Beattie, 974 F.2d 



10 



1309, 1313 (Fed. Cir. 1992) (declarations from those skilled in the art praising the claimed 
invention and opining that the art teaches away from the invention should be considered); In re 
Sullivan, 498 F.3d 1345, 1352 (Fed. Cir. 2007). 

B. Claims 24-29, 31-34, And 44-47 Are Allowable 

Claim 24 defines a method that includes triggering a bandwidth test. The bandwidth test 
comprises sending a bandwidth request to each terminal, registering a bandwidth of an associated 
part connection after each hop and receiving assembled data relating to bandwidth available for 
each terminal. Claims 25-29, 31-34 and 44-47 depend directly or indirectly from claim 24 and 
therefore also contain these limitations. 

The cited art does not teach or suggest the bandwidth test recited in claim 24. For 
example, there is no bandwidth testing done in the system disclosed by Albuquerque et al. The 
Examiner states that Albuquerque et al. teaches a bandwidth test at paragraphs 27 and 28 (Office 
Action, at 5). To the contrary, Albuquerque et al. only teaches a computation of available 
bandwidth by a bandwidth manager overseeing a particular private network. The bandwidth 
manager taught by Albuquerque et al. would fail whenever other networks are traversed, such as 
the internet, because without a test there would be no information about available bandwidth 
from these other networks. (See e,g. Albuquerque et al., Figures 2 and 4, ^ 21, 24-26). 

1. The Cited Art Does Not Teach Or Suggest Bandwidth Tests 

The cited prior art does not teach or suggest any bandwidth test that involves sending a 
bandwidth request to each terminal, registering a bandwidth of an associated part connection 
after each hop and receiving assembled data relating to bandwidth available for each terminal as 
required by claims 24-29, 31-34 and 44-47. The Examiner states that the cited prior art discloses 
a bandwidth manager that determines the flow on a link between terminals and an access point 
that calculates if there is enough bandwidth available in a network at paragraphs 28, 29 and 66 of 
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Albuquerque et al. (Office Action, at 6). However, no portion of the Albuquerque et al. or any 

other cited art teaches or suggests sending a bandwidth request to each terminal, registering a 

bandwidth of an associated part connection after each hop, nor receiving assembled data relating 

to bandwidth available for each terminal. 

Claim 24 explicitly requires "triggering a bandwidth test, the bandwidth test comprising 

sending a bandwidth request to each terminal, registering a bandwidth of an associated part 

connection after each hop and receiving assembled data relating to bandwidth available for each 

terminal." At page 2 of the Office Action, the examiner cites paragraph 66 of Albuquerque et al. 

as disclosing this element of claim 24. The word "test" does not appear in paragraph 66. 

Instead, paragraph 66 says "changes in link speed are reported to the BM." The Examiner relies 

on this teaching saying "Accordingly, since it is able to identify the link speed it is seen to do 

perform bandwidth tests." (Office Action, at 3). In reaching this conclusion, the Examiner is 

improperly using Applicant's disclosure to read into Albuquerque et al. that which Albuquerque 

et al. do not teach or suggest. In saying "changes in link speed are reported" Albuquerque et al. 

suggests continuous monitoring, not testing. Furthermore, there is nothing in the Albuquerque et 

al, reference that tells a reader what is done to cause the reporting of the link speed. It is 

improper for the Examiner to conclude that Albuquerque et al teach or suggest a bandwidth test 

as required by claim 24 from a disclosure that merely recites monitoring of link speeds 

experienced by terminals. 

2. The Cited Art Does Not Teach Or Suggest Bandwidth 
Requests Sent To Terminals 

The system disclosed by Albuquerque et al. does not disclose any bandwidth request 

being sent to any terminals. Instead, bandwidth requests are transmitted by terminals to an 

access point. The access point then utilizes a bandwidth manager to allocate bandwidth for that 
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terminal To the extent the Examiner is suggesting that the system disclosed by Albuquerque et 
al. be modified to read on the requirement that bandwidth requests be sent to terminals, the 
proposed modification of the Albuquerque et al. reference is improper since it would change the 
principle of operation of the prior art invention being modified. MPEP § 2143.01 . 

Albuquerque et al. explicitly requires access points to request bandwidth, not terminals. 
In fact, the removal of such an element that the prior art identifies as necessary is an indicia of 
the non-obviousness of the pending claims. See In re Edge, 359 F.2d 896, 149 U.S.P.Q. 556 
(CCPA 1966). 

3. The Cited Art Does Not Teach Or Suggest Any Bandwidths Of 
Associated Part Connections Being Registered After Each Hop 

Albuquerque et al. also do not disclose or suggest any bandwidths of associated part 

connections being registered after each hop The only registrations of bandwidth disclosed by 

Albuquerque et al. is the maintenance of a registration table via flow registration units FRs that 

operate from a plurality of terminals. (Albuquerque et al, fflf 33, 37, Table 2). The bandwidth 

manager BM may also manage such a reservation table. Id at ^ 42. None of these bandwidth 

registrations are registrations of bandwidth of associated part connections being registered. To 

the contrary, this is only a reservation of bandwidth required by flows experienced by a 

particular terminal from a utilization of a full connection, such as a link. Id. at % 42. There is no 

bandwidths of part connections being registered after each hop in a particular connection path 

taught or suggested by the cited art. 

4. The Cited Art Does Not Teach Or Suggest Any Assembly 

Of Data Relating To Bandwidths Available For Each Terminal 

Moreover, Albuquerque et al. do not disclose or suggest any receiving of assembled data 
relating to bandwidth available for each terminal. As admitted in the Office Action, 
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Albuquerque et al. only disclose an access point that "calculates if there is enough bandwidth 
available in the network." (Office Action, at 6), There is no receiving of any assembled data 
relating to bandwidth available for each terminal as part of a bandwidth test disclosed or 
otherwise suggested in the cited prior art. 

C, Claims 48-52 Are Allowable 

Claim 48 requires a computer to include a network resource test device connected to at 
least one of the network resource allocation device, the performance characteristic providing 
device, and the network resource distribution memory. The network resource test device is 
configured to oversee a bandwidth test, the bandwidth test comprising sending a bandwidth 
request to each terminal, registering a bandwidth of an associated part connection after each hop 
in a communication path between each terminal and the computer, and receiving assembled data 
relating to bandwidth available for each terminal via the associated part connections in each 
communication path. 

The cited art does not teach or suggest a network resource test device as required by 
claims 48-52. As discussed above with reference to claim 24, none of the cited art teaches or 
suggests any running of any bandwidth test. Nor does the cited art teach or suggest a network 
resource test device configured to oversee such a test or a bandwidth test that includes registering 
a bandwidth of an associated part connection after each hop in a communication path between 
each terminal and the computer, and receiving assembled data relating to bandwidth available for 
each terminal via the associated part connections in each communication path. It is respectfully 
requested that the rejection of claims 48-52 be reversed. 

D. Claim 54 Is Allowable 

Claim 54 defines a method for substantially real time transmission of a software 
component that includes the step of if the computed amount of available bandwidth resources is 
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equal to or greater than an amount of bandwidth necessary to transmit the software component to 
the requesting terminal, reducing the at least one lower priority process such that the at least one 
lower priority process is still able to utilize some bandwidth and transmitting the software 
component to the requesting terminal. 

None of the cited art teaches a reduction of a lower priority process such that that one or 
more lower priority processes are still operational. Indeed, the cited art teaches away from such 
a limitation. For example, Albuquerque et al. teach that any lower priority process be eliminated 
or rejected in the event a higher priority process requires all the bandwidth being used by that or 
reserved for that process to be released. (Albuquerque et al., f 46, Figure 5). 

At pages 3-4 of the Office Action, the Examiner contends that paragraph 44 of the 
Albuquerque et al. reference teaches a reduction of the at least one lower priority process such 
that the at least one lower priority process is still able to utilize some bandwidth. To the 
contrary, this paragraph states that "bandwidths reserved may be temporarily halted or rejected 
and lose their reserved bandwidths. n This paragraph does not teach or suggest a reduction of 
bandwidth for a connection that permits a terminal or process to still be able to utilize some 
bandwidth that was previously assigned to it as required by claim 54. This paragraph expressly 
teaches that all the bandwidth that was previously assigned to a lower priority process be 
removed from that process and reallocated. 

The Examiner also argues that paragraph 44 of the Albuquerque et al. reference teaches a 
"best effort mode" and that this best effort mode is only a lowering of reserved bandwidth. 
(Office Action, at 3). To the contrary, paragraph 44 of the Albuquerque et al. reference teaches 
that in "best effort mode" that "bandwidth is not reserved for the flow," (Albuquerque et al., Tf 
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44), That bandwidth was completely removed, That flow is not permitted to use any portion of 

the bandwidth that was previously assigned to it as required by claim 54. 

The cited art alone or in any combination fails to teach or suggest all the limitations of 

claim 54. It is respectfully requested that the rejection of claim 54 be reversed. 

II. Rejection of Claims 33-34 as Obvious in View of The Combination of 
Albuquerque et al. And U.S. Patent Application Publication No, 
2003/0097443 to Gillett et al. 

Claims 33-34 depend directly from claim 31 and indirectly from claims 29, 27, 26, 25 
and 24. These claims are at least allowable because the claims from which they depend are 
allowable as discussed above. Further, the cited art does not teach or suggest any of the 
requirements of claims 33 or 34. 

A. Claim 33 Is Independently Allowable 

Claim 33 includes the requirement that the claimed method include generating a load 
request in response to the temporary rejection of the load request. The Examiner cites paragraph 
59 of Gillett et al. as disclosing such a limitation and admits that Albuquerque does not disclose 
such a limitation. (Office Action, at 19). In the Office Action, the Examiner states that that 
Gillett et al, reference "discloses if the edge server lacks sufficient capability to service the 
request at the required level of performance, the manager may reject or redirect the request. 
Redirecting the request is seen to be generating a load request in response to the temporary 
rejection." (Office Action, at 19 (emphasis added)). 

To the contrary, Gillett et al. teaches that a manger may redirect a request instead of 
rejecting it. There is no rejecting of any request taught by Gillett et al. that generates any load 
request. To the contrary, Gillett et al teach that a request may either be rejected or may be 
redirected for another device to respond to a redirection of a request, which is essentially a 
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transfer of a request to another device, is not a temporary rejection nor any generation of a load 
request in response to a temporary rejection. 

Claim 33 also includes the limitations of claim 31, which requires that the temporary 
rejection be in a message sent to requesting terminal. The temporary rejection of claim 33 is a 
temporary rejection issued to a requester in a message sent to the requester. No such rejection is 
taught by Gillett et al. in paragraph 59. When a request is transferred by a server to another 
server as taught in paragraph 59 of Gillett et al., no such message is sent to the requesting 
terminal issuing any temporary rejection. Therefore, Gillett et al. further fails to teach or suggest 
any sending of a temporary rejection to a requesting terminal. 

The cited art fails to teach the limitations of claim 33. Claim 33 is allowable over the 
cited art, 

B. Claim 34 Is Independently Allowable 

Claim 34 includes the limitation that a permanent rejection be generated after a plurality 
of temporary rejections have been generated for a load request or after determining that the 
amount of a bandwidth necessary to transmit the software component is greater than a maximum 
available bandwidth. As with claim 33, the Examiner admits that Albuquerque et al. do not 
teach or suggest this limitation. (Office Action, at 20). Instead, the Examiner relies on 
paragraph 59 of Gillett et al. to reject claim 34. (Office Action, at 20). 

The Examiner claims that a transfer of a request to different servers is the issuance of a 
number of different temporary rejections and that a request that is ultimately rejected by a server 
is a permanent rejection. Essentially, the Examiner has used the same rationale used to reject 
claim 33. (Office Action, at 20). As noted above with respect to claim 33, Gillett et al. do not 
teach any temporary rejections nor such rejections being sent to a requester in a message. To the 
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contrary, no such rejection is ever offered or provided to a requester when a server disclosed by 
Gillett et al. transfers a request to a different server. This is not a temporary rejection as required 
by claim 34, let alone a plurality of temporary rejections. 

Nor does Gillett et al. teach or suggest the issuance of any permanent rejection that is 
issued after a plurality of temporary rejections have been issued. As discussed above, Gillett et 
al. do not teach or suggest a plurality of temporary rejections being issued. 

The cited combination of art fails to teach or suggest all the limitations of claim 34. 
Claim 34 is therefore allowable. It is respectfully requested that the rejection of claim 34 be 
reversed. 

Ill, Rejection of Claim 52 as Obvious in View of The Combination of 
Albuquerque et al. and U.S. Patent No. 6,222,856 to Krishnan et al. 

Claim 52 depends directly from claim 48. As noted above, claim 48 is allowable over the 

cited art. Therefore, claim 52 is at least allowable because claim 48 is allowable. As discussed 

above, the cited prior art does not teach or suggest any running of any bandwidth test. Nor does 

the cited art teach or suggest a network resource test device configured to oversee such a test or a 

bandwidth test that includes registering a bandwidth of an associated part connection after each 

hop in a communication path between each terminal and the computer, and receiving assembled 

data relating to bandwidth available for each terminal via the associated part connections in each 

communication path. It is respectfully requested that the rejection of claim 52 be reversed. 
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CONCLUSION 



For at least the above reasons, reversal of the rejection of claims 24-29, 31-34, 44-52 and 

54 and allowance of these claims are respectfully requested. 

Respectfully submitted, 

Dated: August 26, 2010 /Ralph G. Fischer/ 

Ralph G. Fischer 

Registration No. 55,179 

BUCHANAN INGERSOLL & ROONEY PC 

One Oxford Centre 

301 Grant Street, 20th Floor 

Pittsburgh, PA 15219-1410 

(412) 392-2121 

Attorney for Applicants 
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Claims Appendix 

The claims on appeal: 

24. A method for substantially real time transmission of a software component after 
receiving a demand for the software component from a requesting terminal of a network 
comprised of a server and a plurality of terminals, the requesting terminal being a terminal of the 
plurality of terminals, the method comprising: 

triggering a bandwidth test, the bandwidth test comprising sending a bandwidth request 
to each terminal, registering a bandwidth of an associated part connection after each hop and 
receiving assembled data relating to bandwidth available for each terminal; 

prior to initiating transmission of the software component, determining via the bandwidth 
test if a present bandwidth is sufficient for transmission of the demanded software component to 
the requesting terminal by identifying at least one lower priority process currently using 
bandwidth of the existing network that each has a lower priority than the demand and computing 
an amount of available bandwidth resources that is obtainable from reducing bandwidth 
resources assigned to the at least one lower priority process, 

if the computed amount of available bandwidth resources is equal to or greater than an 
amount of bandwidth necessary to transmit the software component to the requesting terminal, 
reducing or freezing the at least one lower priority processes and transmitting the software 
component to the requesting terminal; and 

if the computed amount of available bandwidth resources is less than the amount of 
bandwidth necessary to transmit the software component to the requesting terminal, inhibiting or 
rejecting transmission of the software component. 
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25. The method according to claim 24 wherein the amount of available bandwidth 
resources is also calculated according to a specified upper limit of a transmission time for 
transmitting the software component to the requesting terminal. 

26. The method according to claim 25, wherein the amount of available bandwidth 
resources is available to the requesting terminal and is included in the demand. 

27. The method according to claim 26 wherein the server has access to the software 
component and the amount of available bandwidth resources. 

28. The method according to claim 27 wherein the bandwidth test provides a positive test 
result if the amount of available bandwidth resources is suitable for a real time application, or 
wherein the bandwidth test provides a positive test result if the amount of available bandwidth 
resources is suitable for a substantially real time application, 

29. The method according to claim 27 wherein information regarding the present 
bandwidth is made available by a network resource manager and is updated on request by the 
server or after a period of time. 

3 1 . The method according to claim 29 wherein if the amount of available bandwidth 
resources is less than the amount of bandwidth necessary to transmit the software component, a 
message is sent to the requesting terminal, the message comprising a temporary rejection or a 
permanent rejection of the load request, 

32. The method according to claim 31 further comprising displaying the message to a 
user of the requesting terminal. 
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33. The method according to claim 31 further comprising generating a load request in 
response to the temporary rejection of the load request. 

34. The method according to claim 31 wherein the permanent rejection is generated after 
a plurality of temporary rejections have been generated for a load request for the software 
component or after determining that the amount of bandwidth necessary to transmit the software 
component is greater than a maximum available bandwidth. 

44. The method of claim 24 wherein the amount of bandwidth necessary to transmit the 
software component is at least partially defined by a transmission rate requirement provided in 
the demand. 

45. The method of claim 44 wherein the amount of available bandwidth resources is 
calculated by a network resource manager that is connected to the server. 

46. The method of claim 45 wherein the network resource manager is connected to an 
available bandwidth memory that has data on bandwidths assigned to processes using network 
bandwidth resources and priorities for these processes. 

47. The method of claim 46 wherein the network resource manager is also connected to at 
least one of the terminals and wherein the available bandwidth memory is periodically updated 
with new data for the bandwidths assigned to processes using network bandwidth resources and 
priorities for these processes. 

48. A computer configured for connection to a plurality of terminals of a network and 
configured to transmit a software component to a requesting terminal of the plurality of terminals 
after receiving a demand for the software component from the requesting terminal if bandwidth 



22 



necessary for transmitting the software component to the requesting terminal is determined to be 
available, the computer comprising: 

a network resource allocation device, the network resource allocation device configured 
to assign resources of the network to the terminals and reassign resources of the network from 
one terminal to another terminal; 

a performance characteristic providing device connected to the network resource 
allocation device; 

a network resource distribution memory connected to the network resource allocation 
device and the performance characteristic providing device, the network resource distribution 
memory having stored data on bandwidths assigned to processes using bandwidth resources of 
the network and priorities for these processes; 

a network resource test device connected to at least one of the network resource 
allocation device, the performance characteristic providing device, and the network resource 
distribution memory, the network resource test device configured to oversee a bandwidth test, 
the bandwidth test comprising sending a bandwidth request to each terminal, registering a 
bandwidth of an associated part connection after each hop in a communication path between 
each terminal and the computer, and receiving assembled data relating to bandwidth available for 
each terminal via any associated part connections in each communication path; 

the performance characteristic providing device configured to determine whether an 
amount of bandwidth exists that is sufficient for transmission of the demanded software 
component by accessing the data stored on the network resource distribution memory to identify 
at least one lower priority process using bandwidth of the network that each has a lower priority 
than the demand in the network and calculate an amount of available bandwidth resources that is 
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obtainable from reducing bandwidth resources of the network assigned to the at least one lower 
priority process; and 

the network resource allocation device configured to reduce or freeze the network 
resources assigned to the at least one lower priority process and transmit the software component 
to the requesting terminal if the computed amount of available bandwidth resources is equal to or 
greater than an amount of bandwidth necessary to transmit the software component to the 
requesting terminal; and 

the network resource allocation device configured to inhibit or reject transmission of the 
software component if the computed amount of available bandwidth resources is less than the 
amount of bandwidth necessary to transmit the software component to the requesting terminal. 

49 The computer of claim 48 wherein the computer is a server or is comprised of a 

server. 

50. The computer of claim 48 wherein bandwidth demand data is also stored in the 
network resource distribution memory, 

51. The computer of claim 48 wherein the performance characteristic providing device is 
a portion of the network resource allocation device. 

52. The computer of claim 48 wherein the network resource allocation device is also 
configured to periodically update the data stored in the network resource distribution memory. 

54. A method for substantially real time transmission of a software component after 
receiving a demand for the software component from a requesting terminal of a network 
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comprised of a server and a plurality of terminals, the requesting terminal being a terminal of the 
plurality of terminals, the method comprising: 
triggering a bandwidth test; 

prior to initiating transmission of the software component, determining via the bandwidth 
test if a present bandwidth is sufficient for transmission of the software component to the 
requesting terminal by identifying at least one lower priority process currently using bandwidth 
of the existing network that each has a lower priority than the demand and computing an amount 
of available bandwidth resources that is obtainable from reducing bandwidth resources assigned 
to the at least one lower priority process, 

if the computed amount of available bandwidth resources is equal to or greater than an 
amount of bandwidth necessary to transmit the software component to the requesting terminal, 
reducing the at least one lower priority process such that the at least one lower priority process is 
still able to utilize some bandwidth, and transmitting the software component to the requesting 
terminal; and 

if the computed amount of available bandwidth resources is less than the amount of 
bandwidth necessary to transmit the software component to the requesting terminal, inhibiting or 

rejecting transmission of the software component. 
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Evidence Appendix 

None. 
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Related Proceedings Appendix 

None. 
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